Technicians verified Workday name fields and confirmed renaming intent with users (including preferred-name and middle/second-name preferences and collecting private contact addresses when users were unavailable). The Okta renaming workflow was invoked (via Okta Workflows invoke URL) to update the Okta profile and the iu.org username/email, and execution was confirmed using Okta admin pages and Workflows notifications. All rename actions, confirmations, cancellations, aborted renames, and downstream fixes were tracked on an internal renaming checklist and follow-up tickets. Renames typically caused brief user downtime (~10–15 minutes) and client-side cache/sync delays; Teams and Office 365 often continued to show old display names/addresses for hours to days, and Outlook contact cards or shared/brand mailboxes sometimes remained stale. The automation occasionally produced malformed usernames for hyphenated, compound, middle‑initial, or preferred‑name cases (including consecutive dots); those renames were aborted to avoid invalid mailboxes or corrected manually after the workflow completed. ProxyAddresses (mail-aliases) were observed to sometimes not update or propagate and required separate manual correction and tracking. Several downstream systems did not receive automated changes and required manual updates or follow-up tickets (examples: single-entry 1Password records, EPOS/Care, AB Tasty, academy systems, Atlassian/Jira); Egencia continued to apply changes via a nightly HR-feed CSV. Where Okta wrote displayName into Atlassian and background jobs later retriggered and reverted values, affected Jira/Confluence entries were manually corrected and tracked. Local sign-in issues caused by UPN/local-account mismatches were resolved by signing users out and back in, administrator-initiated password resets, or—on multiple macOS endpoints—by re-provisioning. Mac endpoint cases commonly required a full device reset/re-provisioning; technicians advised preserving OneDrive and other local data and performed backups before resetting. All manual corrections and downstream follow-ups were recorded in the renaming checklist and subsequent tickets.

Two resolution patterns were observed. In cases tied to HR records, the user initiated a name/title change in Workday; the change required lead approval in Workday and then propagated to connected systems via directory synchronization (identity management). Propagation updated Microsoft services (Outlook, Teams, Microsoft account/SharePoint), course-management displays, and other connected systems, and was observed to take up to about two weeks. In other cases where the display value was controlled by the application or identity provider, an administrator directly updated the relevant field (for example, the Okta 'Salutation external' field or the Atlassian account display name), which immediately corrected the display in the affected application. It was noted that some profile fields are not editable by end users in the UI and required administrative changes in the authoritative system or the target application.

Access problems were resolved after support identified the authoritative account or device sign‑in method for the affected system, corrected the record or device state, and confirmed successful sign‑in or profile discoverability. Observed resolutions included: corrected canonical usernames and profile fields in authoritative systems (examples: CARE account name fixes that allowed successful sign‑in and profile discovery); administrator‑sent password resets or password‑reset emails that restored Microsoft/Okta/Office access; correcting recorded or stored email addresses when an application used an email address as the login key (no password reset required for those apps); verifying and restoring required Okta group membership; merging or removing duplicate application records and escalating application‑side record fixes to the owning teams (examples: Moses/EPOS name-field and duplicate-entry fixes); identifying separate non‑SSO application accounts and forwarding requests to the app owner to create or reset the app‑specific account (examples: DCWeb, SiteFusion). Device sign‑in failures were addressed by delivering one‑time access/recovery codes in several cases, reinstalling macOS for a local account conflict, and in at least one instance running a script that reset and reconfigured Windows Hello which resolved intermittent sign‑in loops and device recognition problems. Support also observed administrator refresh/sync of a user’s permissions in the identity system breaking an Office‑installation sign‑in loop, and clarified SSO routing when provisioning (for example a misconfigured Workday setting that blocked Atlassian/Service Portal SSO because the Service Portal authenticated via Okta). For third‑party sites, verifying which email address was being used (stored or cached credentials) resolved app‑specific numeric errors (example: Keywordtool.io error -895025148). Each incident was closed after the authoritative identity or device access method in the affected system was corrected and successful access was confirmed.

Investigations found duplicate or legacy records, missing profile entries, or stale proxy addresses that retained ownership of email/proxy attributes, group memberships, or resource ownership in external systems. Resolutions consolidated users to the intended internal/SSO account by recreating missing profile entries or removing duplicate/legacy records and clearing stale proxy addresses; where deletion or merge was not possible, duplicate downstream accounts were explicitly labeled (for example “(do not use)” / “(nicht benutzen)”) to prevent user confusion. Confluence group memberships and space ownerships were reassigned or replicated to the SSO account before legacy records were removed when necessary. Directory-sync mappings and Azure AD/Okta configurations were corrected so the updated identity state propagated to IT service portals and SSO, and Workday cost-center mappings were updated where legacy records had been receiving approvals. When automatic provisioning/import failed, a manual Okta user import was executed to create/import the missing user, and external accounts that were processed as “known user” were internalized during the import. After consolidation, sync propagation, manual import, or labeling, IT Service Portal content and links appeared as expected, users could be added to requests, recovery-email and IU‑Mail assignments attached to the intended account, Confluence access and course/assignment mappings aligned to the SSO account, and Workday approvals routed to the correct approvers. Tickets requesting new accounts were closed when an existing account was present (status recorded as "won't do") and requesters were advised to use the dedicated "Report access problem" IT Service Portal form for actual login/access failures; clearing browser cache or using alternate portals was noted as a useful diagnostic but the root causes were identity record ownership and sync state.

Access and functionality failures were resolved by correcting account presence and permission state at the layer where the failure occurred. Missing managed application accounts were created and invitation workflows completed; after users accepted invitations, sign-in and dashboard access returned. Where application roles or permissions were insufficient or incorrect (for example a CARE bot account lacking Bearbeitungszugriff for Prüfungsleistungen and Antragsverwaltung), the account roles/permissions were aligned with a working reference user and, after permission propagation and the user signing out and back in, the errors and missing functionality cleared. Automation/service accounts were reprovisioned as regular user accounts when API access was unnecessary and logins were verified before assigning application-level rights. On macOS, long-term administrative accounts were used to grant required local permissions or to add users to the admin group; after those changes device-level features such as screen sharing functioned again. For app deployment issues where installations were blocked by pending manager/approver approval in the Company Portal (Unternehmensportal), manager approval was requested or approver assignments were changed and IT enabled the app for the user in the Company Portal; apps already present in the portal (for example JASP) were confirmed visible and newly enabled apps (for example LibreOffice) became installable within about an hour. In all cases resolution was confirmed by successful sign-in and restoration of the previously blocked feature, installation, or dashboard view.

Incidents were resolved by addressing the Apple ID/iCloud account association either by adding an iCloud Mail address to the existing Apple ID or by creating/signing in with a new Apple ID via Apple’s web portal. In one case an iCloud Mail mailbox was created and added to the Apple ID linked to the corporate iPhone; after the iCloud address was associated the device cleared the email-association prompt and resumed normal operation (the exact mailbox name did not affect the outcome). In other cases where on-device creation failed or produced errors, a new Apple ID / Apple e‑mail was created through the Apple account web portal and then signed into the iPhone and MacBook (verification completed); after that the devices synced and became compatible. When account changes were performed on an Apple device (iPhone/iPad/Mac), the new or updated iCloud address propagated to other systems and PCs reflected the updated login.

The account was created with the requested billing configuration (payment method and auto-topup) and the zero‑data‑retention option enabled. C-level approval and GDPR/data-residency details (data processing located in France) were recorded. A dedicated service account was provisioned and integrated with Microsoft authentication for the it-bops service principal, and credentials were reissued via SAFE/1Password after the original share expired so the team could access them.

Investigations consistently identified two main causes: downstream systems taking independent, permanent copies of identity attributes at account creation, and intermediary IAM/provisioning processes (notably SOAP/EPOS and Okta, plus manual provisioning actions) writing or restoring attributes or failing to copy group memberships. Recorded resolutions and actions included: - Quercus retained an edu.libf.ac.uk email captured at account creation; backend administrative correction of the stored email fixed the display. - The Competency App’s missing competency mappings were restored after the EmployeeID stored in the Competency App was corrected. - AD, Azure AD (AAD) and Okta group memberships for a target account were aligned to a reference user and the Employee ID field was populated to restore expected access and group-based roles. - A myCampus record containing a private GMX address was corrected by replacing it with the user’s IU Mail and saving the record; a separate surname inconsistency between myCampus and Workday was escalated to HR. - myCampus/Care display-name and username were manually updated when legal-name changes did not propagate; the same updates were reapplied after values reverted due to IAM writes. - An access outage affecting Klausurensystem and myCampus was traced in CARE logs to SOAP/EPOS writes that had overwritten username changes; timestamped EPOS logs were used to identify and align the correct username across records. - An EPOS recovery-email attribute was successfully updated to a private GMX address and the change was saved and confirmed. - A Microsoft/Bing Chat access failure was resolved after a missing birthdate was added to the Microsoft/IU profile; the absent birthdate had been preventing the service from launching. - An instructor account with an outdated iubh address had its email rewritten in the provisioning system and the user was notified; account-creation/approver guidance was provided when a new instructor account was required. - A Pulse Survey delivery failure was traced to a missing Workday Primary Work Email (likely caused by an Okta sync issue); the Primary Work Email was added in Workday (the authoritative source) to restore downstream delivery. - A finding that students could edit Date of Birth in MyLIBF was recorded and routed into the formal data-change process. Where intermediary IAM writes were implicated, timestamped logs (EPOS/CARE/Okta) were used to identify the correct source values for reconciliation and the required administrative-change pathways were documented in each case.

The mailbox and Azure AD identity were aligned by updating the mailbox primary SMTP and SMTP proxy addresses and by changing the Azure AD userPrincipalName/sign-in name to the requested CAMA-service value while preserving required aliases. Display name, primary SMTP and UPN were synchronized so the service account used the new departmental identity for email and sign-in without losing existing alias routing.

Directory display-name and surname attributes were updated in the institution’s identity sources (Active Directory and Okta) and corresponding myCampus and any external/affiliate records were updated to reflect the corrected name. Minor spelling corrections were completed in Okta when the issue only affected automated welcome messages and Microsoft 365 display names. Where the primary email/login and mailbox required change, the mailbox and login were changed to the new surname-based address while the existing password was retained. When users still could not sign in on replacement or upgraded devices despite using the retained password, support reconciled duplicate or legacy username/User Principal Name entries (removed or aligned stale aliases) and corrected account provisioning attributes. Missing group memberships that impacted network/Wi‑Fi authentication and OneDrive access were restored. Login tests were performed on replacement devices using the updated login and retained password and propagation to downstream systems was verified; users were informed of the change and access confirmation was obtained.

Support reviewed the listed Academy user records, corrected incorrect primary email addresses in the user directory, and confirmed remaining accounts already had correct addresses. Corrections were applied to the directory entries referenced by CARE/EPOS so email routing matched the updated primary addresses, and the support team verified the affected accounts for successful mail delivery after the changes.

Support retrieved and provided the disk-encryption recovery key to the user via secure email or the vendor recovery link. In some incidents the recovery key allowed an immediate unlock and users regained access to the local hard drive, email, and their account. In at least one case the user obtained the recovery key via the provided link and performed a full OS reset; after the reset the device and access to the exam system returned to normal.

Support provisioned nonstandard local and service accounts on a case-by-case basis and recorded associated asset links in the inventory. For event and unmanaged devices, support created local Windows administrator accounts on unmanaged Dell Precision/Latitude laptops, configured Office 365/service accounts on those devices, recorded device and service tags in the asset inventory, and coordinated temporary special handling for the assets. For restricted variants of existing users, support created mirrored accounts (for example a b. account modelled on b.cmarsden) and adjusted permissions so the account had only network-related access. For kiosk devices, support created the requested standard kiosk account, ensured the computer-name pattern included “Kiosk,” and configured group membership as confirmed by the requester. Where provisioning was tenant- or application-specific, support routed requests to the responsible teams: AMOS/test-account requests were referred to the Identity Access Management / Core Component team; libfstudy/EPOS teaching account requests were forwarded to the specialist team who created the account on libfstudy.ac.uk and applied the teaching-account label. Decisions not to provision were recorded: requests for additional personal accounts (for example second personal accounts for works-council members) were refused when they conflicted with licensing or IT policy and requesters were advised of those constraints and the need to involve governance/compliance teams for data-retention or deletion of role-related communications. Requests for local administrator rights on corporate-managed devices were evaluated against approved job profiles; access was denied when the job profile did not permit admin and users were informed, while in other cases local admin rights were granted for documented operational reasons (for example to replace or remove a server). Requests were closed after confirming account creation or denial, recording group/label assignments where applicable, and updating device/service records in the inventory.

Twilio support confirmed they could not perform the name change for the user. The user signed into the Twilio Console, opened the user settings page (https://console.twilio.com/user/user-settings/overview), edited the last name field (changed Kunrath to Uden), saved the profile, and verified the update succeeded.